Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Features
Speaker Deck
PRO
Sign in
Sign up for free
Search
Search
悩ましきインシデント管理 みてねのケース / Incident management is a...
Search
Sponsored
·
Ship Features Fearlessly
Turn features on and off without deploys. Used by thousands of Ruby developers.
→
kohbis
July 31, 2024
Technology
880
2
Share
Embed
Copy iframe code
Copy JS code
Copy link
Start on current slide
悩ましきインシデント管理 みてねのケース / Incident management is a tough
[HRMOS (BizReach)x みてね(MIXI)] SREのお悩みぶっつけ合いLT大会
https://mixi.connpass.com/event/323752/
kohbis
July 31, 2024
More Decks by kohbis
See All by kohbis
『家族アルバム みてね』における インシデント対応との向き合い方 / Approach incident response in Family Album
kohbis
2
320
Kubernetes環境周りの責任範囲をいい機会なので考える / Taking the Opportunity to Clarify Kubernetes Responsibilities
kohbis
2
400
『家族アルバム みてね』におけるAmazon EKSコストとの向き合い方 / Optimizing Amazon EKS Costs: The FamilyAlbum Case
kohbis
4
1.7k
潜在的課題探索活動の近況報告 / Exploration of latent challenges
kohbis
2
170
いま、あらためて考えてみるアカウント管理 with IaC / Account management with IaC
kohbis
3
1.1k
〜『世界中の家族のこころのインフラ』を目指して”次の10年”へ〜 SREが導いたグローバルサービスの信頼性向上戦略とその舞台裏 / Towards the Next Decade: Enhancing Global Service Reliability
kohbis
4
6.8k
Grafana MCP serverでなんかし隊 / Try Grafana MCP server
kohbis
0
980
Custom Prometheus Exporterによる オブザーバビリティ拡張 / Extending observability with Custom Prometheus Exporter
kohbis
1
290
データベースで見る『家族アルバム みてね』の変遷 / The Evolution of Family Album Through the Lens of Databases
kohbis
5
1.6k
Other Decks in Technology
See All in Technology
Snowflakeと仲良くなる第一歩
coco_se
4
430
非定型業務をAI slackbotで自動化する ~ 社内要望を自動壁打ちするbotを作った ~/automating-ad-hoc-work-with-ai-slackbot
shibayu36
0
610
失敗を経て、Harness Engineering で 大切にしたいことを考える / Learning from Failure: What Matters in Harness Engineering
bitkey
PRO
1
320
NAB Show 2026 動画技術関連レポート / NAB Show 2026 Report
cyberagentdevelopers
PRO
0
170
FinOps × AIエージェントで実現する コストインシデントの自動調査
oasis1994liveforever
0
130
データサイエンスを価値につなげるプロジェクト設計 〜 DS一年目が現場で得た気づき 〜
ysd113
1
190
SIer20年! 培ったスキルがスタートアップで輝く時
shucho0103
0
840
AIソロプレナー時代に2ヶ月で20人増員した事業創造会社の開発組織の話
miyatakoji
0
610
スキルと MCP ツール、責務をどう分けるか? AI が迷わないインターフェース設計の戦略
cdataj
1
970
2026TECHFRESH畢業分享會 - 原生還是跨平台? App 開發踩坑實錄
line_developers_tw
PRO
0
850
"何を作るか"を任される エンジニアは、どう育つのか
yutaokafuji
1
610
AI-DLCを活用した高品質・安全なAI駆動開発実践 / AI Driven Development with AI-DLC
yoshidashingo
0
170
Featured
See All Featured
A brief & incomplete history of UX Design for the World Wide Web: 1989–2019
jct
2
390
Designing Powerful Visuals for Engaging Learning
tmiket
1
410
"I'm Feeling Lucky" - Building Great Search Experiences for Today's Users (#IAC19)
danielanewman
231
23k
Documentation Writing (for coders)
carmenintech
77
5.4k
Navigating Team Friction
lara
192
16k
CSS Pre-Processors: Stylus, Less & Sass
bermonpainter
360
30k
Facilitating Awesome Meetings
lara
57
7k
It's Worth the Effort
3n
188
29k
Accessibility Awareness
sabderemane
1
140
Impact Scores and Hybrid Strategies: The future of link building
tamaranovitovic
0
300
Mozcon NYC 2025: Stop Losing SEO Traffic
samtorres
1
250
For a Future-Friendly Web
brad_frost
183
10k
Transcript
悩ましき インシデント管理 @kohbis [HRMOS (BizReach)x みてね(MIXI)] SREのお悩みぶっつけ合いLT大会 2024/07/31
About Me Kohei SUGIMOTO 株式会社MIXI 2022/04 ~『家族アルバム みてね』 SRE X
: @kohbis 2/16 SRE NEXT 2024はMIXIのスポンサーブースにもぜひお越しください!!!
Agenda 1. 「インシデント管理」とは 2. 『家族アルバム みてね』におけるインシデント対応フロー(ざっくり) 3. 悩ましきその①〜④ 4. まとめ
3/16
「インシデント管理」とは • 「インシデント」とは ◦ 「アクシデント(事故)」が発生する前の状況 ◦ 今回は「サービスにおける定義(アラート閾値など)から逸脱した状態」とする SRE本 14章『インシデント管理』より ※1
• “効率的なインシデント管理は、インシデントによって引き起こされる混乱を制限し、 できる限り早く通常の運用に復帰させるための鍵” • “インシデント管理のスキルとプラクティスは、熱意ある個々人のエネルギーを正しい 方向に向けるために存在する” 4/16 ※1 https://www.oreilly.co.jp/books/9784873117911/
『家族アルバム みてね』におけるインシデント対応フロー(ざっくり) 5/16 完了 終息宣言 恒久対応/振り返り 対応 主に暫定対応 切り戻し/緩和 調査
アラート確認 エスカレーション 検知 PagerDuty/Slack オンコール制度については 『家族アルバム みてね』を支えるオンコールエンジニア制度
悩ましきその①
悩ましきその① ランブックの作成・整備不足 理想 • 頻繁に発生する対応はランブック • アラートメッセージにランブックURLがリンクされている 現実 • アラート内容を確認して、慣例的な対処療法
• 「あれ、どこにあったっけ」と社内ドキュメントを検索 できていること • 対応手順の整備は順次実施 • 一部はランブックURLがリンクされている 7/16
悩ましきその②
悩ましきその② 原因調査・特定までの手段が属人的 理想 • 誰が対応してもまず確認するべきもの(ログやメトリクス)が決まっている • 原因となった変更が即座に特定できる 現実 • 「何を確認するか」「どう捉えるか」が属人的
• 都度関連していそうなリポジトリの変更や開発チームに確認 できていること • 一部は手順化されている • 「すぐにエスカレーション」が根付いており (場合によっては)即座に担当チームがロールバック 9/16
悩ましきその③
悩ましきその③ インシデントコマンダー不在 理想 • インシデントコマンダー(「作業」せずに「意思決定」することが役割)が旗振り • ウォールーム(対応指揮室)で統制 現実 • Slackのアラート通知チャンネルでそのまま会話してしまいがち
• 何度目かの「あれ、いま誰がなにやってるんでしたっけ?」 できていること • 最低限決まっていること(エスカレーションなど)は実施 • 作業、確認作業について順次Slackに投稿 • (誰かが言い出せば)対応専用のSlackチャンネルを作成 11/16
悩ましきその④
悩ましきその④ ポストモーテム作成が後回し 理想 • ライブインシデント状況ドキュメントが作成されている • インシデントの対応内容からポストモーテムが(自動)生成される 現実 • とにかく暫定対応が優先されて後回し
• 対応が落ち着いた、完全復旧待ちの時間で作成 できていること • テンプレートが全体に共有され、随時改善 • SREチームだけでなく(インシデントの規模に関わらず) ポストモーテムを書く文化が根付いている 13/16
まとめ
まとめ • 『家族アルバム みてね』の場合、対処療法になっている部分が多い。 • インシデント対応中は復旧が最優先。 明確に場を作らなければ振り返らない • このスライド作成時にチーム内にヒアリングしてあらためて出てきた課題もあった •
あくまでも「できる限り早く通常の運用に復帰させる」(再掲)ことが前提 • インシデント管理フローを改善することによるさらなるメリット ◦ 新メンバーのキャッチアップ/SREチーム以外への移譲 ◦ ランブック作成/整備 恒久対応/自動復旧 やっていき!!!(たい...) 15/16
None